Remove terminology section - #57
Conversation
… fixing definitions
Move and revise terminology section
🏁 PR Preview ClosedThe preview for this PR is now marked as INACTIVE. 🔗 Preview URL: https://fairdo-org.github.io/fdo-architecture-spec/preview/pr-57/ The preview will remain available but shows its inactive status. |
|
The change needs to be discussed by the group, whether we need that section at all. The current list contains terms not used in the document. If we use the respec functions all used terms are links anyway to their definition. |
maximiliani
added
the
Future discussion
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
# Conflicts: # sections/01_fdo-building-block/04-FDO-Profiles.html # sections/02_fdo-processing-block/Introduction.html
self-explanatory setting
introduction in such a way that the definition is redundant.
"syntactic interoperability" since they were not used.
maximiliani
changed the title
| Such specification MUST define the assignment and resolution procedures as well as other organizational | ||
| and technical requirements. | ||
| The term <a>persistence</a> is being mentioned frequently in this document, as in the realm of <a>FDOs</a> <a>persistence</a> is an important property. | ||
| In regard to <a>FDOs</a> <a>persistence</a> is defined as a promise of an initiative or service provider to maintain specifications or services for a long period of time. |
There was a problem hiding this comment.
I think persistence of FDOs not only means that the service/specifications are long-term maintained. Also the identifier itself should be persistent. And the resource being identified by the FDO should be persistent to a certain degree (hence, only resources should be turned into FDOs that are likely around for a longer time).
There was a problem hiding this comment.
Also, I do not see a MUST/SHOULD/MAY in this requirement. A definition is not a requirement and should maybe go to the terminology section instead.
| The <a>PID system</a> MUST support global resolution and therefore global uniqueness of the <a>PIDs</a> at a | ||
| high level of stability. | ||
| A <a>PID record</a> is an at least <a>machine readable</a> structure sent back when resolving a <a>PID</a>. | ||
| A subset of the <a>PID record</a> MAY contain the <a>FDO record</a>, refer to the <a>FDO record</a>, or refer to another <a>PID</a>. |
| <dt><h4 class="rule-heading" id="rule-r1_8">[R1-8] <dfn>Security of <a>PID Systems</a></dfn></h4></dt> | ||
| <dd> | ||
| The <a>PID system</a> MUST offer a high degree of security that only enables the owner of a<a>FDO Record</a> to manipulate it. | ||
| It SHOULD be possible to restrict the access to the whole record or to individual key-value pairs. |
There was a problem hiding this comment.
to individual attributes.
|
The pull request is accepted as subject to change. The pull request is to large. Parts of the changes require additional editing. |
This PR closes #50 and does the following:
Please check if I deleted too many terminology definitions.